An exemplary sensor network 100 is shown in FIG. 1. In this example, a number of sensor nodes 110 are connected through a gateway 112 to the internet 106 so that an application (APP) 108 can obtain data generated by a sensor node 110. The sensor nodes 110 may include one or more sensors (a.k.a., “resources”). In the illustrated example, sensor node 110 includes two resources, R1,1 and R1,N (e.g., a temperature sensor and a smoke detector). The sensor node 110 may also include a processor and a transceiver for sending and receiving data, such as a WiFi or ZigBee transceiver. In some configurations, the sensor nodes, and/or one or more sensors of the sensor node, may be sleeping periodically, otherwise known as “duty-cycling,” in order to limit their energy consumption. Thus, sensor nodes and sensors may be referred to as “sleepy” devices.
As shown in FIG. 1, network 100 may also include a Resource Directory (RD) 102 and a Mirror Proxy (MP) 104. These nodes help to provide application support for discovering relevant sleepy devices, such as sensors. The RD 102 contains reachability information for each registered sleepy device, such as its GW IP address or its own IP address if applicable, and metadata, such as the type of device (e.g., sensor, actuator, parameter, etc.), the associated sensor(s), etc. Another example of metadata is the units of measurement of the measured sensor modality; for example, if the sensor of the device is a temperature sensor, a request to the device for sensor data could result in the retrieval of a value expressed in degrees Celcius. The MP 104 contains recent information generated by a sensor. This information may be provided to the MP 104, for example, by the sensor itself when it is in an “awake” state.
As described in Application-aware Integration of Data Collection and Power Management in Wireless Sensor Networks, by Qi et al., J. Parallel Distrib. Comput. 67(9): 992-10006 (2007), a request from an application 108 can be directed to the MP 104, or alternatively, to the actual sensor, depending on the “accuracy” requirements of the application. For example, if an application requires a highly accurate temperature reading (e.g., the most up-to-date temperature reading), then in many circumstances it would be better for the application to send the request directly to the sensor (assuming the sensor is not sleeping). On the other hand, if the application does not require such an accurate temperature reading, then it may be acceptable for the application to obtain the temperature measurement data from the proxy.
There is a need for methods, apparatuses, and computer program products that can effectively meet application accuracy requirements while at the same time reducing energy consumption in the sensor network.